What is the business case for thermocouple based power meters when you can get the same function with silicon at a lower price:


<>


One of the applications which accelerated development these detectors was the Cell Phone industry which required accurate signal strength readings (RSSI). One of he first devices that Hams used for this function was the NE604 FM IF system which had an accurate RSSI detector. This device is still available as the SA604A which has a wider temperature range:





Alas, technology moves on.


Mike N2MS

On November 19, 2018 at 4:42 PM RFI-EMI-GUY <rhyolite@...> wrote:

Is there any other company on the planet who produces 50 OHM thermocouples? It seems odd that such a thing is unobtainable.

Peter,

it seems to be possible. This is exactly what this guy has done:
(This type of sensor is also known as Bolometer, apparently.)





However, I would not expect a terribly good accuracy.
To get rid of the ambient temperature impact, two resistors can be used where the one of the resistors is always kept, say, 30K hotter than the other. This way the ambient temperature cancels out.

?

What is the business case for thermocouple based power?meters when you can get the same function?with silicon at a lower price:

On November 19, 2018 at 4:42 PM RFI-EMI-GUY <rhyolite@...> wrote:

Is there any other company on the planet who produces 50 OHM thermocouples? It seems odd that such a thing is unobtainable.

On Nov 20, 2018, at 9:12 AM, Artekmedia <manuals@...> wrote:

Thermocouples with an embeded 50 ohm resistor..The 50 ohm resistor is the heater and thermocouple generates a voltage
proportional to the heat gnerated in the resistor

Dave
manuals@...

On 11/20/2018 7:41 AM, Glenn Little wrote:
Are these thermocouples or thermistors?

These are different.

Glenn
WB4UIV

On 11/19/2018 11:45 PM, John E. Burgar wrote:

General Microwave used to make thinfilm 50 ohm thermocouples for their power meter sensors. I don’t know if they are in business any more. Regards, John Burgar

*From:*[email protected] [mailto:[email protected]] *On Behalf Of *RFI-EMI-GUY
*Sent:* Monday, November 19, 2018 1:42 PM
*To:* [email protected]
*Subject:* Re: [HP-Agilent-Keysight-equipment] Issue with homemade diode power sensor for HP meters

Is there any other company on the planet who produces 50 OHM thermocouples? It seems odd that such a thing is unobtainable.

--
-----------------------------------------------------------------------
Glenn Little ARRL Technical Specialist QCWA LM 28417
Amateur Callsign: WB4UIVwb4uiv@... AMSAT LM 2178
QTH: Goose Creek, SC USA (EM92xx) USSVI LM NRA LM SBE ARRL TAPR
"It is not the class of license that the Amateur holds but the class
of the Amateur that holds the license"

--
Dave
Manuals@...
www.ArtekManuals.com

Are these thermocouples or thermistors?

These are different.

Glenn
WB4UIV

On 11/19/2018 11:45 PM, John E. Burgar wrote:

General Microwave used to make thinfilm 50 ohm thermocouples for their power meter sensors. I don’t know if they are in business any more. Regards, John Burgar

*From:*[email protected] [mailto:[email protected]] *On Behalf Of *RFI-EMI-GUY
*Sent:* Monday, November 19, 2018 1:42 PM
*To:* [email protected]
*Subject:* Re: [HP-Agilent-Keysight-equipment] Issue with homemade diode power sensor for HP meters

Is there any other company on the planet who produces 50 OHM thermocouples? It seems odd that such a thing is unobtainable.

--
-----------------------------------------------------------------------
Glenn Little ARRL Technical Specialist QCWA LM 28417
Amateur Callsign: WB4UIVwb4uiv@... AMSAT LM 2178
QTH: Goose Creek, SC USA (EM92xx) USSVI LM NRA LM SBE ARRL TAPR
"It is not the class of license that the Amateur holds but the class
of the Amateur that holds the license"

?

Hello,

A simple task...

But it is NOT IEE488.2 compliant, so will not respond to such things as
*IDN? etc.? (In fact, traffic like that can totally mess it up at times,
as can other automated tricks to attempt to catalogue "live" devices on
the bus..)

Modern GPIB systems will handle all the global un-listen, selected
device addressing and so on for you, making life much easier.? If you
create your own GPIB controller, you have to do all that yourself.

Make sure you know it's device address on the bus.? Ours is defaulted to
a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the
detail in our manual!)? The address setting is a bank of switches
internally.??? If you need to "scan the bus" to find it, you may need to
manually reset the thing after you know it's address, as it's a simple
state machine in hard logic internally, and can get "upset" by command
data it cant understand.

Anyway, when you know it's bus address...?? And it's Talk Mode is set to
"Normal".

Send it the command '9A+I' (not the quotes!) with no trailing terminator
byte, with or without EOI asserted, it doesn’t care about that.? That
command instructs it to send back a reading scaled in Watts.? (Or '9D+I'
in which case It will scale in dB/dBm.)

Use Watt's initially, as a no input signal condition, will still result
in a valid reading!

Give it a little time to figure things out...

When you then ask the system to read back the resulting "measurement".

The 436A will send a 14 byte fixed format ASCII string to the
controller, ending in a CR/LF pair, so your GPIB system needs to be
configured to stop reading when it sees a LF byte (ASCII code 10, or
0x0A)? The 436A does not use the EOI line, so you MUST configure your
bus controller to recognise that LF byte to signify the end of it's
reply, or to stop reading after 14 bytes have been received.

The first byte (byte 0) is the status. ('P' = valid reading.? Anything
else is under/over range.)

Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).

Byte 3 is a sign (ASCII space = +) or and ASCII -

Bytes 4..7 are the measured value, an implied decimal point is
immediately after byte 7.

Byte 8 is always an 'E'.

Byte 9 is always a - sign.

Bytes 10 .. 11 is the Exponent.

Bytes 12..13 are CR/LF

It's all ASCII characters, so no "funny" stuff.

The above comes from table 3-4 on page 3-25 of the operating and service
manual.

It's up to you to process that string to test for validity, and extract
the value.

It is highly recommended to get a copy of at operator/service manual.?
(I only have a dead tree version.)

Hope this helps.

Dave B (G0WBX)


--
Created on and sent from a Unix like PC running and using free and open source software.
::

Hello,

Is this working with the 82357, it would be a great starting point. Although I just don’t understand why interactive IO doesn’t work.?

Has anyone experienced differences between interactive IO and using the libraries - I guess interactive IO just is an interface to the libs?

My best bet right now is that REN should be controlled (pulled inactive) for reading data from the 436. I just don’t know how to test this with the 82357/VISA libraries.?

Regards,

?Staffan

On Monday, November 19, 2018, Daun Yeagley <daun@...> wrote:

Hi Staffan

The physical layer for IEE-488 itself is essentially unchanged from the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the * commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a "non-488.2" communication using the Agilent IO libraries.? In other words, those nifty commands are not available to the old "R2D2" command structure instruments.? I guess I'll include that listing here, for others to see as well.? This code sets up and gets readings from an HP3478A voltmeter, which is pre-488.2 (R2D2 "language")

Daun

Daun E. Yeagley II, N8ASB

On 11/19/2018 4:01 PM, Staffan wrote:

Hello,

Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!

Regards,
? Staffan