Posts by Paradigmnoia

    Good job Paradigmnoia!

    I snuggled in the 2.2 k resistor into a new RS232 header along with a 1K in series with the DTR lead, and installed that into a gutted VGA header housing. Shoe Goo used to back-fill converted DB9 housing (hood) to keep the TX resistor and entire RS232 connector from pulling out of cable.


    Next a Sparkfun RS232 to TTL converter was bored for a crimped and soldered lead to the DTR pin via the perpendicular bend at the back of the RS232 DB9 connector, shrink tubed over the main board, Molex connector aligned with the 4 other pins, and supported with a blob of shoe goo.


    The Reed data logger basically sends data words non-stop. One word for each thermocouple, each apparently read at the instant before reporting the word. I was turning the DTR off, changing the thermocouple from one to another TC port, heating the TC with my fingers, and turning the DTR back on again (which turns back on the data stream). The next reading for the changed items had the changes immediately effected in the data. This seems to mean that there is no large buffer in the Reed device storing up any information long-term. There also seems to be no simple way to get the data sent from the Reed to begin with the first TC first, when receiving it, so I probably need to parse each word, update a bunch of registers, and at each time stamp event read back the most recent temperature registers in the right TC port order for the Arduino SD data log spreadsheet. It is tempting to spy on the Reed data feed to the SD drive inside of it, instead, where temperature data is already processed into the right order for its own spreadsheet.

    Before Browns Gas can become a full member of the club, it needs to win a gas vs gas challenge. Browns Gas versus oxypropane and and bottled oxyhydrogen.


    Just to bring this up to speed, I already burnt a pure tungsten welding rod in half with oxypropane from a cheap torch kit.

    I also read the flame temperature by IR (using the same IR band and emissivity settings as for the Browns Gas reports) for oxypropane and got about 85 C.

    (I will not burn/heat radioactive stuff with any torch to see if the radiation drops).

    So today I got new RSR232 cable info ... which disagrees seriously from the manual (page 15).

    Now the 3.5 mm jack base is the signal (rather than the tip), there is no RS232 ground connection, and 3.5 mm jack tip goes to a new terminal, neither of which the Rx and Tx wires go to .

    wtf

    Edit: tested and this works. The user manual is BS.

    The Sparkfun RS232 - TTL level shifter (with or without the female DB9 connector) has only circuit board connections to three pins of 9: Tx, Rx, and Ground.

    Currently, this only works on a RS232 to USB on a laptop serial monitor but at least I can see the data enough to work out decoding it now.

    The revised DB9 wiring utilizes a neat voltage level manipulation circuit but seems odd without a real ground, and so the TTL shifter needs re-wiring, and there a bazillion suggestions on the Internet for tying DB9 pins one way and another with zener diodes to sort through ...

    The 3.5 mm jack has the base tied to the cable jacket foil, but will be carrying 5V at the jack tip, unreferenced to the receiving side ground except at the power supplies.


    Edit2:

    In case someone else runs into this, since it is unusual, the Reed Datalogger uses a DTR asserted signal from the receiving end, normally supplied by a PC DB9 serial port. This is typically a +9 to +12 V positive signal with some very weak current carrying capacity (about 35 mA). This DTR voltage goes up the RS232 adapter cable to the Reed datalogger, where (inside) it connects to the base of a signal transistor. The high logic RS232 signal then comes back out of the datalogger, (using this voltage supply, through the internal transistor), and goes back down the cable to the Tx pin of the adapter cable, and ultimately to the Rx pin of the (RS232) receiving end. (Negative voltage signals are also sent down this same output signal wire, as well as a zero V (neutral) idle signal.)


    It seems that this DTR voltage can be high enough, even at +5V, to operate (most of) the RS232 to TTL level shifter/inverter devices typically available. However, a resistor (and possibly a diode) should be installed in series to prevent trouble if wired up wrong somewhere along the way. So, in theory, the DTR line can be supplied (with caution) by the +5V Arduino voltage output, and (with more caution) possibly by an Arduino +5V digital output pin set to high logic. The Tx signal from the datalogger connects to the receiving RS232 Rx pin as usual. The ground wire is not connected to anything on the datalogger end. [This is an output only system, and it is unclear if the DTR signal is being used by the data logger for its intended purpose also. However, it seems technically impossible for the datalogger to send any signal without the voltage supplied by the receiver end DTR +voltage signal.]
    (Not all devices connected this way can necessarily use the low +5V at DTR, and may require more voltage, up to +12V, in order to output the RS232 signals properly, especially over any great cable lengths.)


    It is still unclear if the RS232 DTR logic low (negative voltage!) is required in this case, but it seems not.


    Apparently some anemometers output two wire RS232 using this system.


    There are some devices that use the RS232 RTS logic low (negative voltage, as low as -12V) combined with the RS232 DTR logic high (positive voltage) to make a large voltage differential (up to 24V) to supply some circuits.


    EDIT3:

    Finally the RS232 data comes out other than zeros and a few random other bits. I found a manual for a device using the same base circuit board which has an extra connection.

    See B&W image below. Compare this to the WRONG page 15 version of the REED manual. (Ignore some data byte info that are for an anemometer only).

    Without the additional 2.2k resistor, basically only zeros (00) are sent to the serial plug.

    .

    Looking at the Reed Instruments manual, it talks about "An USB RS232 lead." There is no such thing and the reference to RS232 might be wrong. It looks like it might really a USB connection with the two wires being the D+ and D- of USB 2 or USB 3.


    It looks like they sell an expensive cable to connect to USB. It is not clear if this has any electronics or is just a phono plug to D+ D- cable. You could make one by splicing old USB cable to an old phono plug cable.


    https://www.grainger.com/produ…AfyFdudo:20200127173156:s


    The older versions were only RS232, and later a RSB to USB adapter became necessary with the disappearance of RS232 ports in new computers.

    Pure USB communication is totally different, as it uses differential voltage between the two signal lines. The RS232 cable has only two wires in it: Ground and Tx

    Plugging in the RS232 cable to a RS232 to USB adapter (simulated RS232 port), I can receive a data stream on my laptop, through a serial monitor.

    Data from the laptop serial monitor, through the USB adapter looks like this: (a new line appears every two or three seconds)

    Edit: There are available RS232 to USB adapter cables with electronics built in, but that leads to decoding RS232 to USB then USB into TTL, instead of RS232 direct to TTL at the Arduino, adding another signal processing event, which slows down the entire device.

    The most common problem with RS232 is needing to switch Tx and Rx. Tx of the sender needs to go to Rx of the receiver. Some cables have Rx and Tx internally swapped, some do not. Murphy's law says you always have the wrong one.


    Other possible problems are the handshake signals. RTS must be asserted, sometimes requiring an extra jumper on the interface even if you are using only a 2-wire cable.

    I have seen some examples where several of the DB9 pins are linked in the cable end, (6 to 1 and 4, etc.). Which I think fakes out the handshakes. I may try that. It seems like there is no buffer on the RS232 data logger end. It just spits out 16 characters every 2 seconds, and whatever reads them on the receiving end has to be ready for them. Serial2.available() doesn’t work at all. It is never available. Something shows up on the Arduino end, since the RS232 to TTL level shifter lights up the Tx out LED. I think maybe the data logger feeds out End Word characters nonstop until a New Word begins(?). I will see if the manufacturer of the data logger has some better documentation. The manual has the bare minimum of information.


    See page 15 if interested: http://www.reedinstruments.com…/manual/sd-947-manual.pdf

    If you hate the IDE see if you can program using a conventional text editor like Emacs or VIM and then run the results in a separate console window. If you are running Linux or Mac, I find that most open source IDE tools can copy and paste, but sometimes I have to resort to guerrilla tactics.

    I don’t mind the IDE. For some strange reason it is like there is a separate clipboard for the IDE, so one can cut and paste within the IDE, but try and copy from another page and paste to the IDE and whatever was copied or cut from the IDE last time pastes instead.


    Anyways everything was working smoothly until I tried to read the RS232 signal (2 wire only!) from my usual data logger, in order to incorporate that into the sketch data log. I have an RS232 to TTL level shifter, wired everything thing up, checked the Tx and Rx wires end to end, and nothing happens. There should be a 16 bits-long word but nothing comes out in either single bits or strings and with only two wires (Tx and ground), there is no way to poke the RS232 side into action. It is possible that the level shifter doesn’t like only one signal wire. So today’s diagnostics involves plugging in an RS232 to USB cable and seeing if the laptop can see it working...

    Paradigmnoia I've done some Arduino and Raspberry programming for my own projects. I would not recommend Raspberry for what you are doing. Which Arduino are you playing with? Which logging shield? Where are you located? (I'm in Seattle area.)

    I am using an Arduino Mega2560 with an Adafruit data logging shield.
    Starting to get the hang of it. I was able to put zeros in front of the time single digits, and work out proper incremental time samples based on Unix ms timing (rather than just a delay). The most annoying part is that stuff copied from off IDE won’t paste into IDE.

    I know nothing of Arduino or Raspberry programming and haven’t programmed anything since maybe 35 years (raw hexadecimal) but yesterday I spent about 3 hours wrestling with new parts to get the serial monitor of a Arduino and data logging shield to “print” a time stamp every two seconds. Still getting some random extra characters in the time, so looking at that today.

    https://www.adafruit.com/product/2651100 is 96 more than you need, I think. 2 on inlet, and 2 on outlet is sufficient. Check them against alcohol thermometers.

    Ideally two on the outlet, two on the inlet, one ambient nearby, and one for the inside box lid for emergency notice (like acrylic box in danger of melting), one for the heater/inside reactor, one for outside of the heater/reactor...


    Also there is a nice Bosch air pressure (in hPa, +/- 1 hPa accuracy), temperature, and humidity sensor, all in one. The air pressure sensor is good enough to be used as an altimeter. I think one in the calorimeter box and one in the outlet should be good enough to verify the outlet velocity. (Used as a manometer). I’ll have get one working first.


    https://www.adafruit.com/product/2652

    Plot from new power supply data, below, with a section with electrical tape 12 mm wide on Inlet TC, non-sticky side facing out, perpendicular to airflow.

    (This part was cut off the earlier test due to accidentally turning off the data logger).


    The heater temperature now stays dead flat, so I call that a huge improvement. Now I can test outlet air velocity etc. with confidence.


    Also, I switched the heater TC to one installed between the bubble foil and the acrylic box, on the RH side of the lid, just to see how hot that gets.

    .


    .

    Why run a 48V power supply at 50.0, i.e. past its rated operating voltage? Might burn it out or be unstable. Why not run it at 48V?

    The power supply is only running 200 W out of the 350 W capacity and 4 A out of the 7.5 A capacity. It comes with a little trim pot for V right next to the wire connection header. I think it is normally used for big LED systems that are run in 4 banks of 12 V.

    The 48 V DC 350 W power supply arrived early today, a nice surprise. Wired it up, installed it, set it to 50.0 V (it is adjustable +/- about 4 V). And three hours later, still 50.0 V. AC ripple 0.0076 V. Awesome.


    Now I am assembling an Arduino data logger to (eventually) get all calorimeter sensors onto the same time stamp.
    Apparently I can have 100 thermocouples logging simultaneously (offset by a few ms for each one) but I doubt I will try it.

    And so, perhaps lost in the up and downs (above) is that when the calorimeter inlet TC is working normally, the open resistor, at 450+ C, glowing dull red wires inside the box has the same delta T as the 20 x 50 cm SS cylinder with the resistor sealed inside it, and an outside T of about 100 C, at the same 210 W (ish) input power.


    So there you go. A normal range of size and shape differences of the heat source at the same input power makes no difference to the calorimeter at steady state.

    Anyways, in the spirit of science, I opened up the SSVR box and installed a choke and caps assy from a microwave to clean up the noise on the line from the triacs. Hoping to stabilize the heater input better. The “set” output voltage inevitably wanders around after a while and it is annoying. I have a 48 V DC 350 W power supply coming to simply plug in for the 200 W runs for voltage stability.


    So, while testing that out, I also just added a 13 mm wide piece of black electrical tape to the inlet thermocouple to sort-of simulate the former bubble cover (about 5 cm long). The tape is flat with the thermocouple centred in the length, and the not sticky side is facing the inside of the calorimeter box. After cooling down from touching it, it looks like a solid 3 C increase in inlet temperature. I’ll turn it 90 degrees in a while (to align it with the airflow instead of against it). Then I’ll try to aim it at the heater, like a fat antenna.


    Edit: Fantastic! I turned the tape stuck to the inlet TC 90 degrees, (so it is aligned with the airflow), and it went right back to ambient (down 3 C), and fairly quickly, too.

    .....

    Surprise #2: Aiming the tape at the heater coil seems to get an inlet temperature between the perpendicular and the parallel to air flow positions (it is roughly 45 degrees to airflow). Maybe it makes a back-eddy that pulls heated calorimeter air towards it when it is non-parallel to airflow?


    And after taking the tape strip off to cool the TC to ambient again, I stuck the strip back on, this time with the tape non-sticky side facing out, perpendicular to flow (TC exposed facing into the box), the inlet temperature jumped up 5 C.

    .

    The spikes in inlet temperature (below) are from touching the TC while adding tape.

    .

    It may be easy for you to do, but the rest of us have only bits and pieces to work with.

    It was not a parameter. In some cases atmospheric pressure was included, but the effects from that were tiny, and there was really no point to it.


    You can run the numbers and see that humidity could not affect this data measurably. It would be lost in the noise. Look at the sensitivity and the error bars for this instrument. Also, there is no clean data from this lab. Look at the variation in ambient temperatures. The noise from that translates to a ~2 W error. Mizuno made heroic efforts to reduce this, but it is still very noisy.

    The humidity itself has a small effect, but if humidity is not being used, then perhaps a standard condition is being used, which also specifies the temperature of the air, which has another effect, if say for example velocity was read in NTP units but being used in STP calculations without a commensurate adjustment.


    But my original point was that excess heat and calibration heat information from the same calorimeter, same blower speed, etc., for even several different power ranges, should allow reversing some calculations in order to spit out a velocity value, and that value, even when wrong (skewed really), for whatever reason, will end up with almost the same velocity result for each example from that calorimeter.

    Yes. You noticed the problem almost immediately, and so would anyone else who compares the inlet to ambient temperature. It is impossible to miss. You might say, "but suppose we don't compare the inlet to ambient?" I think that only a person who has never done experiments and has no common sense and no feel for how they should be done would make that mistake. In our recipe, Mizuno and I did not mention this step, because we assumed everyone who does the experiment knows to do this -- along with many other things.


    I am glad you mentioned this. But I think you should acknowledge that it is a trivial issue that will never be a problem, because it surely be discovered immediately.

    If it were not for the obvious increase in inlet temperature correlating to the heater and outlet temperatures and sudden drop back to ambient, it might look like ~100 W of excess heat.

    .

    Elsewhere, you mentioned the effect of changing humidity on the experiment. It is okay to list that, but I think you should have said, "we know that humidity cannot be a problem because it does not vary much in Sapporo, it hardly varies at all indoors, and even at the extremes it is too small to have a significant effect." I think that when you mention that but you do not say it has no significant impact, you do a disservice to the discussion here. You give the impression there may be a problem where there isn't.

    I only meant that if the data were particularly clean, it would be possible to determine if humidity was used as a parameter. Does that matter? Maybe not much, but what it probably means that Standard Conditions were not used, which requires some different constants for heat calculations than Actual Conditions. Which only matters if you want the right answer.

    The inlet TC must equal the ambient temperature. If it does not, something is wrong. You should always monitor both.


    This problem would never cause a mistake, because you would always see that the inlet does not equal ambient, so you would know there is something wrong. You measure ambient with another TC and with an alcohol thermometer. In other words, with an instrument based on a different physical principle. Problems that affect a TC cannot affect an alcohol thermometer.


    You also verify the outlet temperature and air speed with multiple instruments based on different physical principles, so there is no possibility they will be wrong. They cannot go wrong to the exact same extent.

    I noticed the problem almost immediately after installing what I thought would work as an IR blocker. I was surprised at how much the effect was. The effect was increased (I think) due to the high radiant power of the open resistor. Now it is back to normal. The Swan/Crane thing was just for fun after a late night messing with it. A little extra tape... I am also an artist...