HP 50g Connection to Multimeter
ob...@yahoo.com
rate of 600. I found a small program in Google Groups that allows you
to lower your baud rate below 2400 (the lowest range in the 50g).
Unfortunately I have not been able to establish a connection to the
millimeter. I am not sure if it is due to the "baud modifying program"
or due to another issue.
I have been able to connect to my computer with both devices (the 50g
and the multimeter) at 600 baud. The multimeter's specs indicate that
it sends data at 600,n,7,2.
To send ASCII to the multimeter (any character should initiate
feedback per the multimeter manufacturer) I am using the XMIT command
(it returns a 1 in stack-1 which is good), and to receive information
I use the SRECV command (it returns a "" 0 in stack-1 which is not
good). It appears that no items are stored in the buffer, which may
indicate that the IO-parameters may not be matching and nothing is
being received.
Does any one know of other means or 50g commands that can work to
troubleshoot this issue?
Regards,
Bryan
TW
> I am trying to connect my HP 50g to a multimeter (MAS345) with a baud
> rate of 600. I found a small program in Google Groups that allows you
> to lower your baud rate below 2400 (the lowest range in the 50g).
> Unfortunately I have not been able to establish a connection to the
> millimeter. I am not sure if it is due to the "baud modifying program"
> or due to another issue.
I know it will connect at ranges like that no issue. It does work
properly.
> I have been able to connect to my computer with both devices (the 50g
> and the multimeter) at 600 baud. The multimeter's specs indicate that
> it sends data at 600,n,7,2.
I suspect the 2 might be the issue. I am correctly interpreting that
as 2 stop bits? If so, I don't think the calculator can handle it as
it only does 1 stop bit. Am I wrong on this anyone?
> I use the SRECV command (it returns a "" 0 in stack-1 which is not
> good).
What is your STIME value? If it is extremely short it might be timing
out.
TW
ob...@yahoo.com
I tried setting STIME to 10-sec, but it still did not work.
ob...@yahoo.com
>
> - Show quoted text -
The multimeter protocol indicates the following:
Baud rate : 600bps
No parity check
7 bits ASCII code
2 stop bits
I had my computer set to these parameters when I connected each device
to it, both worked. Independantly however, independantly having the
50g connect to another device may not be so easy. Is there any way to
change the stop bits in the 50g?
Bob Blaylock
<e9de36b8-8867-42f8...@e10g2000prf.googlegroups.com>,
ob...@yahoo.com wrote:
> The multimeter protocol indicates the following:
>
> Baud rate : 600bps
> No parity check
> 7 bits ASCII code
> 2 stop bits
>
> I had my computer set to these parameters when I connected each device
> to it, both worked. Independantly however, independantly having the
> 50g connect to another device may not be so easy. Is there any way to
> change the stop bits in the 50g?
Try setting the HP50g to eight data bits, and one stop bit.
--
Our enemies shall talk themselves to death, and
we will bury them with their own confusion.
--
Remove "HatesSpam" and ".invalid" from email address to contact me.
C Rushton
serial cable. If it's from Samson Cables, you can connect directly to a PC
w/o an adapter but probably need one for other serial devices such as gpsr's
and your multimeter. On the other hand, if your cable is from hpcalc.org you
should need a null-modem to connect to a PC but NOT to the other serial
gizmos.
Chuck
Manny
the serial cable. Both devices as DCE would be incompatible with each
other. One way to do this is with a break out box which allows you to
route each pin on the serial cable independently, as well as see if
data is toggling via led's at each pin.
On Sun, 9 Dec 2007 06:35:03 -0500, "C Rushton" <cwr...@bellsouth.net>
wrote:
Claudio Lapilli
Many of the things I'll write here were already said by other posters,
but I'll compile everything in one message and add my own info:
1) Make sure your TX and RX lines are properly wired (straight or null-
modem cables).
2) The SETSPEED program will work OK at 600 bauds.
3) Set the transmission as 8N1
4) Serial transmissions are LSB, so you need to set the bit 7 (the
MSB) of each character you send to your device (add 128, or OR 128),
in order to simulate the missing second stop bit.
5) All characters you receive will have bit 7 set, so you need to mask
this bit to get readable text (data may look corrupted, but the text
will be there, just AND 127 each char)
Claudio
tomcee
Ensure that the multimeter does NOT rely on other RS232 lines for
powering. As some multimeters are designed to communicate with a PC,
they rely on the other lines (DTE, etc) for power. Your calculator
communication cable likely does not provide these.
The multimeters I've studied are also electrically isolated from the
comm cable, and are optically isolated. IIRC, it did not even use
the conventional TX/RX lines for communication. The (custom) PC
software manipulated other bits in the com port to communicate with
the multimeter.
TomCee
ob...@yahoo.com
wrote:
> In article
> <e9de36b8-8867-42f8-a87c-0a0d3e992...@e10g2000prf.googlegroups.com>,
The first time I tried to communicate with the multimeter my HP 50g
settings were at 8 data bits and one stop bit. However, I amy be
mistaken, I will try it again.
ob...@yahoo.com
I have tried connecting with and without a nul-modem, I have had the
same result both ways. The XMIT command sends the string and returns a
"1" in the first line indicating that it sent the string. However,
when checking the buffer is empty and a SRECV command returns a "0"
with a "TIMEOUT" ERRM.
ob...@yahoo.com
>
> - Show quoted text -
I am not familiar with break out box's but I will do some research,
thank you. Like I mentioned before, I did use a null-modem.
ob...@yahoo.com
>
> - Show quoted text -
I used your program "SETSPEED" to change the baud rate, I confirmed
that it works between my HP 50g and my PC. This would indicate that
it's one of the other IO parameters.
I am afraid that my background is not in electronics, could you please
expand on what you refer to with "add 128, or OR 128" and "AND 127 ea.
character"?
ob...@yahoo.com
>
> - Show quoted text -
Per what I was able to determine the RS232 for the multimeter uses
pins 2 and 3 (probably TX and RX) and pin 7 (probably GND) no other
pinns seem to be connected. How can I determine if the multimeter is
trying to power up through the communication cable? I used the
Hiperterminal software in MS Office to communicate with the
multimeter, it seemed to work as a standard serial cable.
John H Meyers
Bryan:
>> I have been able to connect to my computer with both devices
>> (the 50g and the multimeter) at 600 baud. The multimeter's specs
>> indicate that it sends data at 600,n,7,2
TW:
> I suspect the 2 might be the issue. I am correctly interpreting that
> as 2 stop bits? If so, I don't think the calculator can handle it
> as it only does 1 stop bit. Am I wrong on this anyone?
Would have worked on HP48/49, where 7+2=8+1 :)
(their UARTs were happy either way, IIRC)
Can you set your computer (with HyperTerminal) to 7+2
and then either type on keyboard or send a text file to the calc?
As others have noted, the computer thinks of itself as "DTE" (a terminal)
while older HP48/49 calcs with their cables think of themselves
as "DCE" (a modem), but the third-party maker of the new HP50 cable
may have done the opposite; DTE <-> DCE communication
works without swapping transmit<->receive (TX<->RX),
but DTE <-> DTE or DCE <-> DCE need a "cross-over" ("null modem"),
sort of like mating the ends of magnets,
where N<->S like each other, but N<->N or S<->S don't :)
Doesn't some new cable also need some kind of "jump-start"
to wake it up? (two cables, even with null modem between,
won't connect two calculators, if I read correctly).
[r->] [OFF]
James M. Prange
PC, which is configured as DTE (Data Terminal Equipment),
presumably without using any null modem, it seems that both are
configured as DCE (Data Communications Equipment), so it seems to
me that you should be using a "null modem" adapter or cable for
them to communicate with each other.
Which adapter are you using with your 50g to shift the signal
levels to RS-232 levels? Hpcalc's? Samson Cables'? Home-made?
Other?
In the case of hpcalc's adapter, and I think Samson Cables
adapter, to avoid using up the calculator batteries all the time
that it's plugged in, it powers down when it doesn't sense any
active signal on its receive line (the other device's transmit
line). I assume that either a plus voltage ("space" condition) or
minus voltage ("mark" condition) would be interpreted as an active
connection, but grounded or floating (not connected) (idle
condition) would be interpreted as inactive. Because of this, if
you try connecting a pair of 50g calculators using a pair of
hpcalc adapters plus a null modem, it won't work, because each
adapter is waiting for an active signal from the other before it
powers up. If your multimeter uses a similar scheme to avoid
wasting battery power, then that's a problem.
Do you know whether your multimeter can receive from the
calculator?
Can your multimeter be configured to use anything other than
600,7,n,2?
SRECV should be enough to tell you whether your 50g received
anything, but you could also use the BUFLEN command to check
whether there's anything in the receive buffer (perhaps received
after the SRECV command timed out).
STIME (serial timeout) can be set in steps of .1 from .1 through
25.4, or 0 STIME disables the timeout (wait forever, or until the
CANCEL key is pressed, or the battery goes dead, whichever comes
first). The default timeout is 10. You might want to increase the
STIME value while experimenting.
By the way, although the calculator should give you a low battery
error if the batteries are too low, it would be best to be sure
the AAA cells are reasonably fresh. Or you could power the
calculator through the USB connection (and yes, experimentally,
hpcalc's adapter does work with the USB power only, that is, with
the battery removed).
I can't say for certain for the 50g's serial signal (the ARM
processor's built-in UARTs can be configured in different ways),
but to me it seems likely that they'd have them set up in much the
same way as the 48 series and 49G. For the 48 series, a
transmitted frame (1 byte) consists of 1 start bit (plus voltage,
or space condition), either 8 data bits (plus voltage or space for
0 bits, minus voltage or mark for 1 bits), LSB (Least Significant
Bit) first, or 7 data bits followed by 1 parity bit, then 2 3/16
stop bits. For receiving, a frame is almost the same, with the
exception that only *at least* 1 stop bit is required.
The calculator's parity can be set with the PARITY command. an
argument of 0 results in 8 data bits and no parity bit. the other
values result in 7 data bits, and for 1 the parity is odd, for 2
the parity is even, for 3 the parity is mark (always a 1 bit), and
for 4 the parity is space (always a 0 bit). You can also use -1
through -4, in which case the corresponding parity bit is
generated when transmitting, but the parity bit is ignored when
receiving. The parity value is also stored (as a real number) as
the 2nd element in the reserved variable IOPAR.
Having extra stop bits shouldn't hurt, except that the through-put
(in Bytes per second) will be lower.
For your multimeter, the 600 would indicate the data rate in bps
(bits per second), 7 would indicate 7 data bits, n would indicate
no parity, and 2 would indicate 2 stop bits.
At first look, the above would seem a mismatch with the
calculator, but it's not a show-stopper. If you use no parity in
the calculator, then the multimeter's first stop bit will be
treated by the calculator as the most significant data bit being
always mark (or a 1 bit), thus adding 128 to the byte's decimal
value, and the multimeter's second stop bit will be treated as a
stop bit (the calculator only requires 1 stop bit). But how about
if we use parity on the calculator? In that case, the 7 data bits
will be treated correctly by the calculator, the multimeter's
first stop bit will be treated as a "1" parity bit, and the second
stop bit will be treated as a stop bit. So okay, if we use "mark"
parity, that is, always require a 1 for the parity bit, on the
calculator (do 3 PARITY), then the calculator should receive
correctly from the multimeter. But how about when sending from the
calculator to the multimeter? The calculator's 7 data bits should
be treated correctly by the multimeter, but it isn't expecting any
parity bit, so the mark parity bit will be treated as a stop bit,
and the 2 3/16 stop bits will be treated as stop bits. So the
multimeter's will be sensing 3 3/16 stop bits; more than it needs,
but it shouldn't do any serious harm, only slowing the through-put
a little.
Anyway, use mark parity on the calculator; that is, execute
3 PARITY.
But even if you use no parity on the calculator, the calculator
should receive something (even though its value will be increased
by 128 decimal). If you use odd or even parity, the calculator
should give you a parity error for about half of the bytes. If you
use space parity, the calculator should give you a parity error on
every byte. If you use a negative parity value, the calculator
should receive okay, but the multimeter would probably give you
some sort of framing error when receiving from the calculator.
Since the SRECV command is always timing out, it seems to me that
the biggest problem must be something other than the parity
setting.
--
Regards,
James
John H Meyers
After reviewing entire thread,
I still don't see where you identified
what you are using as an HP50G "serial cable"
o Samson serial cable? [no longer sold]
http://www.samsoncables.com/catalog/prodDetail.cfm?Prod_ID=391
o commerce.hpcalc.org serial cable?
http://commerce.hpcalc.org/serialcable.php
o Home made (or other) serial cable?
o USB <-> serial? (won't work on calc side, needs USB "host")
If the "hpcalc" cable were "awakened" by its own "transmit" signal,
instead of by the remote's, would that solve the issue of
being unable to connect two calcs with those cables?
(does CLOSEIO turn off the calc's own "transmit" line?)
[r->] [OFF]
ob...@yahoo.com
> obr04:
>
> After reviewing entire thread,
> I still don't see where you identified
> what you are using as an HP50G "serial cable"
>
> o Samson serial cable? [no longer sold]http://www.samsoncables.com/catalog/prodDetail.cfm?Prod_ID=391
>
>
> o Home made (or other) serial cable?
>
> o USB <-> serial? (won't work on calc side, needs USB "host")
>
> If the "hpcalc" cable were "awakened" by its own "transmit" signal,
> instead of by the remote's, would that solve the issue of
> being unable to connect two calcs with those cables?
> (does CLOSEIO turn off the calc's own "transmit" line?)
>
> [r->] [OFF]
I have tried both a Sampson serial cable and a hpcalc serial cable
(with and without a null-modem). I open the transmission (the buffer)
with the OPENIO command and keep it open while attempting to send
ASCII characters to the multimeter with XMIT. The transmission of any
character to the multimeter should trigger the return of data from the
multimeter. For some reason the return of data does not occur. I do
not use CLOSEIO in the process.
ob...@yahoo.com
> Since both the calculator and the multimeter communicate with the
> PC, which is configured as DTE (Data Terminal Equipment),
> presumably without using any null modem, it seems that both are
> configured as DCE (Data Communications Equipment), so it seems to
> me that you should be using a "null modem" adapter or cable for
> them to communicate with each other.
>
> Which adapter are you using with your 50g to shift the signal
> levels to RS-232 levels? Hpcalc's? Samson Cables'? Home-made?
> Other?
[To answer yor initial question, I have tried both a Sampson serial
cable and a hpcalc serial cable
(with and without a null-modem).]
> In the case of hpcalc's adapter, and I think Samson Cables
> adapter, to avoid using up the calculator batteries all the time
> that it's plugged in, it powers down when it doesn't sense any
> active signal on its receive line (the other device's transmit
> line). I assume that either a plus voltage ("space" condition) or
> minus voltage ("mark" condition) would be interpreted as an active
> connection, but grounded or floating (not connected) (idle
> condition) would be interpreted as inactive. Because of this, if
> you try connecting a pair of 50g calculators using a pair of
> hpcalc adapters plus a null modem, it won't work, because each
> adapter is waiting for an active signal from the other before it
> powers up. If your multimeter uses a similar scheme to avoid
> wasting battery power, then that's a problem.
[Based on the symptoms this appears to be the possible cause. Could it
be that after the calculator sends the signal (with XMIT) the cable
shuts off?]
> Do you know whether your multimeter can receive from the
> calculator?
[No, I receive no response from the multimeter]
> Can your multimeter be configured to use anything other than
> 600,7,n,2?
[Afraid not, these IO parameters are fixed]
> SRECV should be enough to tell you whether your 50g received
> anything, but you could also use the BUFLEN command to check
> whether there's anything in the receive buffer (perhaps received
> after the SRECV command timed out).
[The result of using SRECV is as follows:
Stack two --------> ""
Stack one --------> 0
and using BUFLEN I get:
Stack two --------> 0
Stack one --------> 1
I will use a 24-second STIME next time I try]
> STIME (serial timeout) can be set in steps of .1 from .1 through
> 25.4, or 0 STIME disables the timeout (wait forever, or until the
> CANCEL key is pressed, or the battery goes dead, whichever comes
> first). The default timeout is 10. You might want to increase the
> STIME value while experimenting.
>
> By the way, although the calculator should give you a low battery
> error if the batteries are too low, it would be best to be sure
> the AAA cells are reasonably fresh. Or you could power the
> calculator through the USB connection (and yes, experimentally,
> hpcalc's adapter does work with the USB power only, that is, with
> the battery removed).
[I have done this before, with a small USB-Solar charger. I was
testing a small GPS program and was running out of batteries in the
50g, the solar charger worked fine]
> I can't say for certain for the 50g's serial signal (the ARM
> processor's built-in UARTs can be configured in different ways),
> but to me it seems likely that they'd have them set up in much the
> same way as the 48 series and 49G. For the 48 series, a
> transmitted frame (1 byte) consists of 1 start bit (plus voltage,
> or space condition), either 8 data bits (plus voltage or space for
> 0 bits, minus voltage or mark for 1 bits), LSB (Least Significant
> Bit) first, or 7 data bits followed by 1 parity bit, then 2 3/16
> stop bits. For receiving, a frame is almost the same, with the
> exception that only *at least* 1 stop bit is required.
>
> The calculator's parity can be set with the PARITY command. an
> argument of 0 results in 8 data bits and no parity bit. the other
> values result in 7 data bits, and for 1 the parity is odd, for 2
> the parity is even, for 3 the parity is mark (always a 1 bit), and
> for 4 the parity is space (always a 0 bit). You can also use -1
> through -4, in which case the corresponding parity bit is
> generated when transmitting, but the parity bit is ignored when
> receiving. The parity value is also stored (as a real number) as
> the 2nd element in the reserved variable IOPAR.
[Next time I try connecting the two devices I will play some more with
the PARITY command and the IOPAR variable]
[When I initially started trying to connect the devices to ea. other I
expected that in the worst case to receive only some illegible ASCII
characters. However, I receive no response at all from the multimeter.
This leads me to believe that your initial assumption that the cable
switches off may be the cause]
> Anyway, use mark parity on the calculator; that is, execute
> 3 PARITY.
[I will try it next time]
> But even if you use no parity on the calculator, the calculator
> should receive something (even though its value will be increased
> by 128 decimal). If you use odd or even parity, the calculator
> should give you a parity error for about half of the bytes. If you
> use space parity, the calculator should give you a parity error on
> every byte. If you use a negative parity value, the calculator
> should receive okay, but the multimeter would probably give you
> some sort of framing error when receiving from the calculator.
>
> Since the SRECV command is always timing out, it seems to me that
> the biggest problem must be something other than the parity
> setting.
>
> --
> Regards,
> James
Please find my response above (in brackets [ ... ] within your text). I
will continue trying to connect the two devices. It may take me a bit
of time, I am fairly new to using the communication capabilities of
the 50g.
John H Meyers
> I have tried both a Samson serial cable and a hpcalc serial cable
> (with and without a null-modem). I open the transmission (the buffer)
> with the OPENIO command and keep it open while attempting to send
> ASCII characters to the multimeter with XMIT. The transmission of any
> character to the multimeter should trigger the return of data from the
> multimeter. For some reason the return of data does not occur.
> I do not use CLOSEIO in the process.
Has two-way communication been established between meter and anything else?
Has two-way communication been established between calc and anything else?
How about a "loopback" test? (unfortunately it is not built
into the self-test, as it was in HP48/49); the "hpcalc" cable
might also be unable to do that, but you could try;
it might be nice if it would turn itself on, for a while,
either upon first plugging into calc
or upon detecting that I/O is enabled (by OPENIO), if possible,
which would then even enable calcs to talk to each other over wire.
If the serial port is enabled for full duplex, with buffering,
then an on-board program might be able to send itself some data
for loopback testing, by first transmitting and then receiving;
I do not have any cable for testing this, however.
I believe it's pins 2 and 3 of the DB9 connector
which need to be connected, to create a loopback
(which was all that HP48/49 needed, but see below)
http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm#db9
http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm#loopback
http://www.airborn.com.au/rs232.html [includes loopback]
http://www.computerhope.com/help/serial.htm [no loopback info]
[r->] [OFF]
John H Meyers
"Using a 'T' plug and a PC to monitor comms"
at http://www.airborn.com.au/rs232.html
Quoting (without the accompanying picture):
The gadget below is a quick 10 minute project
that is really great for monitoring RS232 Comms using a PC.
There are three sockets on our monitoring gadget.
Two of them are connected straight through -
you plug them in series with the devices you wish to monitor -
and the third goes off to another monitoring PC.
The monitoring PC "Sees" on its serial port
both sides of the serial conversation - that is it sees
what is sent by Device 1 and also what is sent by Device 2.
This can be a positive advantage, because you can see
the serial conversation as it progresses between the two devices.
Some serial protocols, however, talk "full duplex" meaning that one end
can start transmitting while it is still receiving from the other end.
This unit cannot monitor full duplex Comms - you will see
gobble-dee-gook where the two transmissions overlap.
If you try this unit, you will be surprised how useful it is, and
how often it works - mostly because many supposedly full duplex installations
still talk half duplex in any case, because that is the sensible way
to write the software. Not bad for one diode and a resistor, huh?
[r->] [OFF]
ob...@yahoo.com
> I forgot to mention the neat section
> "Using a 'T' plug and a PC to monitor comms"
To answer your questions, I have only established two way
communication with the
multimeter and a PC, and between the PC and the 50g.
I have been thinking in purchasing a breakout box to
test each port during communication.
Concerning the T-plug, can I purchase it online?
John H Meyers
> To answer your questions, I have only established two way
> communication with the
> multimeter and a PC, and between the PC and the 50g.
Well, then you have established that both multimeter and 50g
each can communicate in both directions,
which seems to rule out "dead" hardware,
as the question was meant to help diagnose.
> I have been thinking in purchasing a breakout box
> to test each port during communication.
>
> Concerning the T-plug, can I purchase it online?
The site showing its elementary wiring
seems to suggest making it for oneself,
using connectors from Radio Shack or similar shop,
plus the one diode and resistor.
The fact that it would make a mess of "full-duplex" traffic
might make it an otherwise unattractive commercial product.
I'm wondering whether the signal levels need checking,
because some circuits are very accepting of marginal levels,
or even completely out of spec levels,
while others will refuse to talk to anything which doesn't
"speak clearly" -- early 49G calculators like mine, for example,
had a mis-wired serial circuit (an incredible engineering blunder,
which somehow completely escaped all notice or "QC" process),
resulting in wrong signal levels (or sensitivity),
yet many other robust serial devices still worked with it,
while others wouldn't talk to it at all.
The various other commentators have addressed
how to make sure to properly interface "7+2" to "8+1"
as well as try both with and without "crossover" ("null modem"),
so what else is there to do -- replace batteries?
All the same, I know two people who will each talk to me,
but they still won't talk to each other :)
[r->] [OFF]
ob...@yahoo.com
> On Mon, 10 Dec 2007 22:27:03 -0600, obr04 wrote:
> > To answer your questions, I have only established two way
> > communication with the
Just in case, how do I change the Data Bits in the HP 50g? I dont
recall how to do that.
I just tested both devices with the PC at
> Baud rate : 600bps
> No parity check
> 7 bits ASCII code
> 1 stop bits
And they both work, once again just with the PC.
Still a mistery ...
ob...@yahoo.com
>
> - Show quoted text -
After further testing the DB-9 for the multimeter I found out that
pins 2, 3, 5 and pin 7 are connected. This would indicate that
possibly pins 2 and 3 are Tx/Rx, pin 5 is probably GND and 7 ??? Could
this be the power line?
If so, do you know any way to provide power perhaps through a
commercial adapter between the two DB-9 plugs?
Regards,
B
barro
>
> - Show quoted text -
Pin 7 should be RTS
JB
James M. Prange
> Just in case, how do I change the Data Bits in the HP 50g? I dont
> recall how to do that.
With parity set to "none", you'll have 8 data bits and no parity
bit. With parity set to odd, even, mark, or space, you'll have 7
data bits and 1 parity bit.
If the other device is expecting 7 data bits and no parity bit,
then it should treat a mark (1) parity bit as an extra stop bit
(which shouldn't cause any error), thus effectively 7 data bits,
no parity. A space (0) parity bit should be treated as the lack of
the expected stop bit and cause an error.
The argument for the calculator's PARITY command can be:
0: none (8 data bits)
1: odd (7 data bits)
2: even (7 data bits)
3: mark (7 data bits)
4: space (7 data bits)
-1: odd (7 data bits), ignore parity of received bytes
-2: even (7 data bits), ignore parity of received bytes
-3: mark (7 data bits), ignore parity of received bytes
-4: space (7 data bits), ignore parity of received bytes
The calculator stores the parity value (default 0), as a real
number, as the 2nd element in the list stored in the reserved
global variable IOPAR in the home directory.
From the sending device, for odd parity, the sum of the data bits
plus the parity bit should be an odd number; for even parity, the
sum should be an even number; for mark parity, the parity bit
should always be 1; for space parity, the parity bit should always
be 0.
If the receiving device is checking parity, then it should error
out if the parity bit is not as expected.
Of course, when using only 7 data bits, only 128 data values are
possible.
Other than changing the parity setting, the 48 series and 49G
don't provide any way to change the number of data bits.
With the ARM-based models (49g+, 48gII, and 50g), it might be
possible to use ARM code to set up the UART to use 5, 6, 7, or 8
data bits, parity none, odd, even, mark, or space, and either 1 or
2 stop bits, but with RPL code, you have only the parity setting
with them.
--
Regards,
James
James M. Prange
> After further testing the DB-9 for the multimeter I found out that
> pins 2, 3, 5 and pin 7 are connected. This would indicate that
> possibly pins 2 and 3 are Tx/Rx, pin 5 is probably GND and 7 ??? Could
> this be the power line?
As noted before, your multimeter seems to be a DCE device, since,
if I understand correctly, it can communicate with the PC without
using a null modem
With a DE-9 (usually incorrectly called DB-9) connector, normally,
pin 2 would be the data signal from DCE to DTE, pin 3 would be the
data signal from DTE to DCE, pin 5 would be the signal ground, and
pin 7 would be the request to send signal from DTE to DCE.
Request to send is normally a hardware flow control signal, but if
this hardware flow control were actually being used, one would
expect a connection to pin 8, the clear to send signal from DCE to
DTE. If there's no connection to pin 8, then it appears to me that
your multimeter may well indeed be expecting to use a request to
send signal on pin 7 as a power source for its RS-232
level-shifter circuits.
> If so, do you know any way to provide power perhaps through a
> commercial adapter between the two DB-9 plugs?
Assuming that you're using the hpcalc.org adapter (which is
configured as a DTE device) with your 50g, I'd try making a "power
adapter" cable (or use a double-ended shell) with male and female
DE-9 connectors with pins 2, 3, and 5 connected straight through,
plus a power source (5VDC-15VDC; an ordinary 9V battery should
suffice) connected between pin 5 (signal ground) and pin 7
(request to send) of the male connector (no need to connect pin 7
of the female connector). The polarity of the power source
shouldn't matter, but I suppose that it just might, so if one
polarity doesn't work, then try the other. I expect that an AC
power source should also work, but in that case, the *peak*
voltage (not the RMS voltage) should be not exceed 15V. At worst,
if the multimeter really is using request to send as a hardware
flow control signal instead of just a power source, then this will
force it either on or off, without doing any hardware damage to
your multimeter.
Now that I think of it, just in case your multimeter is using
request to send as a hardware flow control signal instead of (or
in addition to) a power source, it would probably be better to
connect the power source positive to pin 5 (signal ground), and
negative to pin 7 (request to send), so that it doesn't "think"
that the calculator wants to send something.
If you want to use your Samson Cables adapter (which is configured
as a DCE device) instead, use a pair of female connectors, with
each connector's pin 2 connected with the other's pin 3, pins 5
and 7 connected straight through, and the power source between
pins 7 and 5, thus making a combination of a "power adapter" and a
null modem in the same adapter. It won't matter which end is
connected to the Samson Cables adapter and which to the mutimeter.
Alternatively, use a male-to-male null modem adapter or cable
between the Samson Cables adapter and a home-made power adapter as
built for the hpcalc.org adapter.
--
Regards,
James
ob...@yahoo.com
> > pins 2, 3, 5 and pin 7 are connected. This would indicate that
> > possibly pins 2 and 3 are Tx/Rx, pin 5 is probably GND and 7 ??? Could
> > this be the power line?
>
> if I understand correctly, it can communicate with the PC without
> using a null modem
>
> With a DE-9 (usually incorrectly called DB-9) connector, normally,
> pin 2 would be the data signal from DCE to DTE, pin 3 would be the
> data signal from DTE to DCE, pin 5 would be the signal ground, and
> pin 7 would be the request to send signal from DTE to DCE.
>
> Request to send is normally a hardware flow control signal, but if
> this hardware flow control were actually being used, one would
> expect a connection to pin 8, the clear to send signal from DCE to
> DTE. If there's no connection to pin 8, then it appears to me that
> send signal on pin 7 as a power source for its RS-232
> level-shifter circuits.
>
> > If so, do you know any way to provide power perhaps through a
> > commercial adapter between the two DB-9 plugs?
>
> Assuming that you're using the hpcalc.org adapter (which is
> adapter" cable (or use a double-ended shell) with male and female
> DE-9 connectors with pins 2, 3, and 5 connected straight through,
> plus a power source (5VDC-15VDC; an ordinary 9V battery should
> suffice) connected between pin 5 (signal ground) and pin 7
> (request to send) of the male connector (no need to connect pin 7
> of the female connector). The polarity of the power source
> shouldn't matter, but I suppose that it just might, so if one
> polarity doesn't work, then try the other. I expect that an AC
> power source should also work, but in that case, the *peak*
> voltage (not the RMS voltage) should be not exceed 15V. At worst,
> flow control signal instead of just a power source, then this will
> force it either on or off, without doing any hardware damage to
> yourmultimeter.
>
> request to send as a hardware flow control signal instead of (or
> in addition to) a power source, it would probably be better to
> connect the power source positive to pin 5 (signal ground), and
> negative to pin 7 (request to send), so that it doesn't "think"
> that the calculator wants to send something.
>
> If you want to use your Samson Cables adapter (which is configured
> as a DCE device) instead, use a pair of female connectors, with
> each connector's pin 2 connected with the other's pin 3, pins 5
> and 7 connected straight through, and the power source between
> pins 7 and 5, thus making a combination of a "power adapter" and a
> null modem in the same adapter. It won't matter which end is
> connected to the Samson Cables adapter and which to the mutimeter.
> Alternatively, use a male-to-male null modem adapter or cable
> between the Samson Cables adapter and a home-made power adapter as
> built for the hpcalc.org adapter.
>
> --
> Regards,
> James
Thank you for your help. I am afraid however, that the addition of a
power source to pin 7 did not help either. I have to do more research
on these types of connectors.
Unfortunately I have not been able to gather information on the RS232
diagram for this MAS345 Multimeter, but I will continue searching. I
will let you know if I ever get it to work with the 50g.
google...@allenwan.com
> In the case of hpcalc's adapter, and I think Samson Cables
> adapter, to avoid using up the calculator batteries all the time
> that it's plugged in, it powers down when it doesn't sense any
> active signal on its receive line (the other device's transmit
> line). I assume that either a plus voltage ("space" condition) or
> minus voltage ("mark" condition) would be interpreted as an active
> connection, but grounded or floating (not connected) (idle
> condition) would be interpreted as inactive. Because of this, if
> you try connecting a pair of 50g calculators using a pair of
> hpcalc adapters plus a null modem, it won't work, because each
> adapter is waiting for an active signal from the other before it
> powers up. If your multimeter uses a similar scheme to avoid
> wasting battery power, then that's a problem.
The "hpcalc" cable doesn't actually do activity detection. The code
for this was written and then commented out after realizing that it
provided no meaningful power savings. The cable only draws 3mA when
powered up and simply opening IO on the 50g increases power draw by
around 15mA to around 30mA.
http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/6dec4019c34f9786
Furthermore, there doesn't seem to be a correct way to implement an
activity time out and power back on afterwards without possibly
dropped characters or glitches.
Instead, the reason the cable shuts down when unplugged from the DE-9
end is the "Auto-Powerdown" feature that comes with the on board
MAX3221.
http://focus.ti.com/lit/ds/symlink/max3221.pdf
This also causes an issue when plugging hp50g's together since neither
side will power up until the other does. The feature wasn't disabled
initially (and there was some debate about this) mainly because of a
fear that other shutdown triggers were very ephemeral and more easily
missed by the microcontroller and so this provided a backup shutdown
trigger of sorts. There was also an initial belief that it saved power
while in use if unplugged from one device and walking to the next. The
power measurements done by Eric and linked to above kind of blew that
out of the water.
There didn't really seem to be a flip side at the time. There was a
perception that people who wanted to do one way transmission from the
calculator could just hack the cable by tying the receive line to V-
(-5v) with a 1k resistor. Eventually, the decision was made to make it
a user call by adding a switch which disables the Auto-Powerdown
feature. The switch is polled by the microcontroller at power on
(which is when the cable is plugged in and NOT when the calculator is
turned on) and if switched on, the microcontroller will drive the
ForceOn pin on the MAX3221 when appropriate to keep the level shifters
running even when the DE-9 side is unplugged.
-Allen
google...@allenwan.com
from Bryan, we were able to get the calculator to communicate with the
Mastech multimeter. The trick was DTR needs to be driven to V+ and RTS
needs to be driven to V- which was discovered from line 408 of marsh.c
(http://savannah.nongnu.org/projects/marsh/ in the download area,
version 0.98), a freely available program which claims to communicate
with the MAS-345. I think this might be intended to work with a
computer set to half duplex with hardware flow control? This also
happens to be the opposite of what the Fluke 89 requires.
From the Fluke 89/87 Remote Interface Specification:
Communication Protocol (model 89-IV and 87-IV)
The Fluke 89-IV and 87-IV have an infrared (IR) serial interface that
is operated in an RS-232 mode:
* 9600 Baud, no parity, 8 bits, 1 stop bit
The IR adapter cable used with the 89-IV and 87-IV gets its power from
the DTR and RTS signals going into its DB9 connector.
The PC RS-232 communications port needs to control these two signal
lines via software, or they can be controlled
by wiring in an external power source. If you wire in an external
power source, be sure to break the DTR and RTS signal lines
going back to the PC. The DB9 connector on the IR adapter cable needs
to have the following lines with the following voltages applied:
* DTR disabled - pin 4 with -3 to -12 volts (or tied to pin 5,
Ground, will work also)
* RTS enabled - pin 7 with +3 to +12 volts
As a side note, the above does not apply to the newer Fluke 187/189
which steals power off of the TX line to drive its optocoupler. Or at
least that's what Scott Thompson and I concluded which makes it the
cleanest/most compliant implementation of optoisolation for serial
communication on a DMM of which I am aware.
So, to get the cable to work, DTR was connected to the V+ pin on the
MAX3221 and RTS to the V- pin. I also had to turn the switch on so
that the charge pumps would start. The baud rate was set to 600 using
the Claudio Lapilli method. And parity was set to mark as per the
instruction given by James Prange earlier in this thread.
-Allen
my email address is mm-dd...@allenwan.com where mm-dd-yyyy is
today's date.
James M. Prange
<snip>
> The "hpcalc" cable doesn't actually do activity detection.
I suppose that that depends on what you mean by "activity
detection". Mine certainly does detect whether the data receive
line is at a valid (mark or space) or an invalid (idle or
floating) level.
> The code
> for this was written and then commented out after realizing that it
> provided no meaningful power savings. The cable only draws 3mA when
> powered up and simply opening IO on the 50g increases power draw by
> around 15mA to around 30mA.
Well, http://commerce.hpcalc.org/serialcable.php says "Very low
power consumption (4 mA when in use, much less when not in use)",
but I'll assume that "in use" refers to when data is actually
being transmitted or received, so I'll go along with 3mA when the
adapter is powered up but idle.
> http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/6dec4019c34f9786
That post also indicates 0.0mA (so presumably less than 0.05mA)
with the calculator turned off. Even 3mA would be a very
meaningful power savings for this case. And the bat+ voltage for
powering the adapter is present at the serial connector whether
the calculator is on or off. So it seems that we'd also want the
adapter to power down when the 50g is off (which can be detected
by the serial port being closed), whether the receive line is
valid or invalid. (Or else unplug the adapter when it's not
actually in use.)
But how to detect whether the serial port is open or closed? It
seems to me that when the port is open, the transmit line must
always be driven to a mark (+3.3V) or space (0.0V) condition. When
the port is closed (including when the calculator is off), I'd
presume that this line would be driven to a space condition or
perhaps left floating. When open and nothing is being transmitted,
the transmit line should be driven to a mark condition (+3.3V)
(like a continuous stream of stop bits), and when something is
being transmitted, it must be driven to the mark condition at
least once (for a stop bit) per frame. So if it isn't driven to a
mark condition at least once per frame time at the lowest bit rate
(longest frame time), then the port must be closed. Any return to
a mark condition would indicate that the port has been opened
(even if not currently transmitting). Presumably this is what the
extra IC (the microcontroller) is for.
> Furthermore, there doesn't seem to be a correct way to implement an
> activity time out and power back on afterwards without possibly
> dropped characters or glitches.
>
>
>
> Instead, the reason the cable shuts down when unplugged from the DE-9
> end is the "Auto-Powerdown" feature that comes with the on board
> MAX3221.
> http://focus.ti.com/lit/ds/symlink/max3221.pdf
Well, the MAX3221 is part of the adapter, so I'd say that anything
that it does is part of what the adapter does.
> This also causes an issue when plugging hp50g's together since neither
> side will power up until the other does. The feature wasn't disabled
> initially (and there was some debate about this) mainly because of a
> fear that other shutdown triggers were very ephemeral and more easily
> missed by the microcontroller and so this provided a backup shutdown
> trigger of sorts. There was also an initial belief that it saved power
> while in use if unplugged from one device and walking to the next. The
> power measurements done by Eric and linked to above kind of blew that
> out of the water.
>
>
>
> There didn't really seem to be a flip side at the time. There was a
> perception that people who wanted to do one way transmission from the
> calculator could just hack the cable by tying the receive line to V-
> (-5v) with a 1k resistor. Eventually, the decision was made to make it
> a user call by adding a switch which disables the Auto-Powerdown
> feature. The switch is polled by the microcontroller at power on
> (which is when the cable is plugged in and NOT when the calculator is
> turned on) and if switched on, the microcontroller will drive the
> ForceOn pin on the MAX3221 when appropriate to keep the level shifters
> running even when the DE-9 side is unplugged.
Making it a user call would indeed seem like a very good design
decision (except for extra cost and design issues), but I don't
find any such switch (even within the shell) on an adapter from
commerce.hpcalc.org.
The description includes "Automatically goes to sleep when
external device is disconnected or when the calculator's serial
port becomes inactive". But "when the calculator's serial port
becomes inactive" is open to interpretation; does that mean only
when the external I/O port is "closed" (or a different external
I/O port is active), or whenever data isn't actually being
transmitted or received?
Using a pull-up resistor to force a disconnected receive line to a
valid state should work, but doing it within the adapter's shell
would require good soldering skills. If someone would rather not
risk tinkering with the adapter itself, a suitable DC voltage
could be applied *through a resistor* between pins 2 (data input)
and 5 (signal ground) of an additional adapter to be used with the
commerce.hpcalc.org adapter. For an additional adapter for use
with the the Samson Cables adapter (configured as DCE instead of
DTE) this would be between pins 3 (data input) and 5 (signal
ground).
So, Allen, where do you get your information about this from?
Were you involved in the design of the adapter?
Do you actually have an adapter from commerce.hpcalc.org?
--
Regards,
James
google...@allenwan.com
> I suppose that that depends on what you mean by "activity
> detection". Mine certainly does detect whether the data receive
> line is at a valid (mark or space) or an invalid (idle or
> floating) level.
I apologize for my misunderstanding. Eric also pointed this out to me.
You do in fact use the term "active" consistently to mean a valid
signal as opposed to my understanding that an active signal has
activity i.e. it changes. So when I wrote that we don't do activity
detection, what I meant was the hpcalc cable doesn't shutdown after a
period (e.g. 30 seconds) of no signals changing (inactivity). This is
notable because Samson's cable does (or at least claims to, I've never
actually seen one). Also the MAX3227 implements this automatically and
refers to it as "AutoPowerdown-Plus".
For more information on how the current version of the "hpcalc" cable
functions, see http://www.allenwan.com/hpcalcserialcable.html
> But how to detect whether the serial port is open or closed? It
> seems to me that when the port is open, the transmit line must
> always be driven to a mark (+3.3V) or space (0.0V) condition. When
> the port is closed (including when the calculator is off), I'd
> presume that this line would be driven to a space condition or
> perhaps left floating. When open and nothing is being transmitted,
> the transmit line should be driven to a mark condition (+3.3V)
> (like a continuous stream of stop bits), and when something is
> being transmitted, it must be driven to the mark condition at
> least once (for a stop bit) per frame. So if it isn't driven to a
> mark condition at least once per frame time at the lowest bit rate
> (longest frame time), then the port must be closed. Any return to
> a mark condition would indicate that the port has been opened
> (even if not currently transmitting). Presumably this is what the
> extra IC (the microcontroller) is for.
The most challenging aspect of the calculator's behavior to deal with
is that the receive line is driven low when the calculator is turned
off or the serial port is closed. For a more detailed explanation of
how this is handled, see http://www.allenwan.com/hpcalcserialcable.html
> So, Allen, where do you get your information about this from?
I don't know. It just came to me. :-)
> Do you actually have an adapter from commerce.hpcalc.org?
I don't. I haven't had any reason to order one since I can make one
myself for much less. :-)
ob...@yahoo.com
> To update everyone on what's happened, after receiving themultimeter
> from Bryan, we were able to get the calculator to communicate with the
> needs to be driven to V- which was discovered from line 408 of marsh.c
> today's date.
I apologize for not updating everyone on this item earlier. Allan
solved the connectivity issue between the MAS345 and the HP-50g. I
would have not been able to solve this issue on my own. I am more
familiar with software than I am with hardware.
If any one is interested I am planning on making a simple program that
will collect data from the MAS345 and process it using the 50G as a
data-logger. I don't imagine too many will be interested due to the
difficulty in connecting the two.
Thank you all for your help with this connectivity issue, all of your
comments contributed to narrowing the issue down, and I also learned
quite a bit from the comments.
Best regards,
Bryan