Looking at the data expected and received on the wire, there could be an extra
inversion after some bits delay until an inverted 1 is detected as a start bit:
00001101 00110000 00110001 01011111 01010011 01010010 01010000 .01_SRP - what
you should see on your scope
01111001 01100111 01010000 01010110 00101011 01111001 01110111 ygPV+yw - what
you probably see on your scope
You should be able to connect your output data directly into any
current PC serial port as they should both work with 0-5V nowadays.
On 2015-08-25 11:35, Brian M wrote:
The earlier suggestion of a missing inverter seems to be the right thing to
chase this evening. I was able to add an inverter and decode the first few
characters on a scope. I get the expected DC1-CR-P-R-S sequence.
Thanks for the input on this. I'll reply back after I've had more time to hack
at this.
On Tuesday, August 25, 2015, Brian Inglis <[email protected]
<mailto:[email protected]>> wrote:
You have too many 1s in your startup string compared to the expected
"PRS_10\r".
If the MCU clock is not 10Mhz then the integrated UART rates will be off,
which should produce framing errors, but do UARTs still detect and systems
report these nowadays, or just pass along garbled data?
Otherwise, garbled data is most often a result of inadequate pin contact,
if the connectors are not seated properly, or the pins or sockets are loose
in their shells.
Age and rough treatment can have that effect.
"Internal hardware jumpers allow these pins to be configured as analog
outputs
to monitor the lamp intensity and varactor voltage for complete
compatibility
with the FRS."
Have you checked the jumpers in the manual Configuration Notes:
"Pin 4: TXD/PHOTO The default configuration uses this pin as an output for
RS-232 data.
Many system parameters (including the lamp intensity) may be monitored via
the RS-232
interface. The function of this pin may be changed to an analog monitor for
the lamp
intensity by removing one resistor (R347) and installing a 10 kΩ resistor
for another (R348)
on the microcontroller PCB."
On 2015-08-24 22:40, Brian M wrote:
I tried through the weekend, double and triple checking wiring and
setup.
I've tried the following methods of getting serial comms working:
PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
PRS10 -> Level Shifter -> BBB UART
PRS10 -> MAX232 -> USB Serial adapter
Shortly after power is applied to the PRS10, I do get a string of
characters. Believe it should be the model information. Instead I get:
wy+VPgy
I guess the good news is that this output appears consistent with each
power cycle of the device. And I'm getting the same results through all
the
hookup methods I've tried.
My minicom settings are for software flow control at 9600 8N1 - from
what
the manual states, this should be the right settings. I've tried screen
as
well - and get the same text. I went crazy trying several other rates
and
setting combinations. No luck.
Maybe I've missed something obvious.
I agree that getting comms going to the MCU are going to be an important
step. How do people address this type of problem? Scope the serial and
try
to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
further steps people try after that? If nothing else I think there's
some
interesting stuff to learn here. I also wouldn't mind tearing out the
electronics, determining if the lamp is good, and attempt to build from
there. I don't know the datecode for the unit, the PCB is marked with a
datecode suggesting 2003? I don't have the full case. I'm trying to
assess
what are reasonable next steps. How do I determine if the MCU is
healthy?
If the MCU is fried, how do I determine if I just need to squeeze a new
MCU
board in there?
Thanks! I appreciate the input so far!
- Brian
PS - after looking again at the signal on the scope, it does seem like
it
is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
what I saw on the main connector.
On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <[email protected]> wrote:
Le 22 août 2015 à 03:40, Bob Camp <[email protected]> a écrit :
Hi
On any microprocessor based gizmo, getting the micro running
(again) is
generally priority number one. It sets everything up and gives
you the
diagnostic
info you need to go further. Garbled serial is better than none
at all.
It suggests
something short of a total MCU death spiral …
Bob
On Aug 21, 2015, at 7:26 PM, Brian M <[email protected]>
wrote:
Dear list -
I have come into possession of a for parts prs 10. I'd like
to try to
repair this device. What I've noticed so far. Serial is
garbled. (Even
at
varying baud rates).
You don’t say how you are connecting to the Rb. The manual
states:
"RS-232 data is sent to the host on pin 4, received from the host
on pin
7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit.
No DTR
or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The
transmit
drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These
levels are
compatible with
most RS-232 line receivers, but does not require their use (a TTL
inverter
may be used
instead), hence simplifies the interface when used inside an
instrument at
the sacrifice of
degraded noise immunity over long lines."
So make sure that you adhere to that.
Lamp isn't lit.
What’s the date code. Early versions may be reaching EOL, though
20yrs id
quoted.
Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are
common failure
modes?
Anything match up with what I describe? Voltages to check
would be
helpful.
The 10MHz out looked okay on a scope. Haven't gone further
yet. I
suspect
the crystal is fine.
Thanks in advance. Happy hacking!
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
